Subject: Re: review of draft-ietf-dlswmib-mib-07.txt

From: Kaj Tesink <[email-masked]>
Date: Mon, 15 Apr 96 11:18:16 EDT

hi david,

looks good. here are my notes to your notes.

kaj

-----------------
At 06:14 PM 4/11/96 EDT, David D. Chen ((919)-254-6182 8-444) wrote:
>Ref:  Your note of Fri, 5 Apr 96 09:30:26 EST (attached)
>
>Thank you for your thorough review.  DlswTimeStamp (item 16)
>is removed, and duration times (TimeTicks) are used which
>I believe is agreed by the WG and consistent with SNANAU WG.

good

>
>(item 14a) "VALID" clause is added for readability, no
>other intention to Counter32 construct.  If you feel strong
>about removing them, we could add similiar info in the DESCRIPTION
>clause, if WG agrees.

see below under 14a comments
>
>Another MIB definition change is all InstancePointer will be
>changed to RowPointer (as agreed in WG).
>
>Do you all agree?  I will put out another draft if no comments in
>the next few days.
>
>Thanks.  Dave
>
>>---------------------------- Note follows ------------------------------
>>Received: from mail.bellcore.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP;
>>   Fri, 05 Apr 96 09:23:33 EST
>>Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1)
>>	id AA27814; Fri, 5 Apr 1996 09:29:19 -0500
>>Return-Path: <[email-masked]@mail.bellcore.com>
>>Received: from  by eve (4.1/4.7)
>>	id AB03977; Fri, 5 Apr 96 09:30:26 EST
>>Date: Fri, 5 Apr 96 09:30:26 EST
>>X-Station-Sent-From: eve.bellcore.com
>>Message-Id: <9604051430.AB03977@eve>
>>X-Sender: [email-masked]
>>X-Mailer: Windows Eudora Version 2.1.1
>>Mime-Version: 1.0
>>Content-Type: text/plain; charset="us-ascii"
>>To: [email-masked] (Shannon Nix), [email-masked], [email-masked]
>>From: Kaj Tesink <[email-masked]>
>>Subject: review of draft-ietf-dlswmib-mib-07.txt
>>Cc: [email-masked], [email-masked]
>>
>>Hi all,
>>
>>Here is finally my review of draft-ietf-dlswmib-mib-07.txt
>>Sorry for the long delay.
>>
>>In general I think this MIB is very good quality.
>>There are a number of tidbits though. The more
>>significant ones include the timestamp issue (item 16)
>>and your Counter32 construct (item 14a).
>>
>>Kaj
>>------------------------------------------------------------------
>>
>>1 - Section 2
>>Align with newer SNMP RFCs (19xx series). See
>>for an example kzm's revision of RFC1573.
>
>agree.  Will use draft-ietf-ifmib-mib-03.txt (2/22/96) as an example.
>
>>
>>2 - Global typo IfIndex --> ifIndex
>
>agree.
>
>>
>>3 - Section 3.2
>>Fix the "work in progress" remark.
>>Its either done, or if not talk only about the things that
>>can be referred to.
>
>agree.  Will remove dependencies on the LLC MIB development.
>
>>
>>4 - Sect. 3.3 2nd bullet
>>Unclear what is implied with "most implementations".
>>- The DESCRIPTION clauses should say unambiguously
>>  what must be created when.
>>- The conformance clauses should state by whom.
>
>agree.
>
>>
>>5 - Sect. 3.4.1
>>Useful to include "[1]" after "Version"?
>>Also the english  in the 4th object maybe
>>ambiguous/unclear in "retrieving inorder the entries.."
>>must be "ordered retrieval of the entries.."?
>
>agree.
>
>>
>>6 - Sect. 3.5.1
>>Despite the example the sentence "Thus, duplication.."
>>is still unclear to me.
>
>To reduce the size of the MIB, information that usually
>are available in two partner nodes (i.e., info exchanged
>between them) are only defined in the MIB as the info
>received.  That is, no objects defined for the info sent.
>That means, manager needs to go to both nodes to find
>out about what actually being exchanged.
>
>The sentence will be reworded to clarify this point.
>
>>
>>7 - Sect. 3.5.3.6 4th line
>>The sentence "For implementations.." should be fixed
>>for similar reasons as item 4 above:
>>- unclear what implementations are referred to
>>- the conformance clause claims that all systems must
>>  support these objects
>
>The MIB does not specify how long the agent needs to
>keep the info of TConnOperDiscTime and TConnOperDiscReason
>after the connection went down.  That is why those
>words were used.  Will change something to be more specific.
>
>>
>>8 - 3.5.3.10
>>Who are "our"?
>
>agree (a dlsw agent).
>
>>
>>9 - Sect. 3.5.3.12 8th line
>>"there should be.." shoould be "the agent must create.."?
>
>agree.
>
>>
>>10 - 3.5.3.10
>>Similar as in item 11 above:
>>- try to avoid options or second guessing
>>- say in DESCRIPTION and conformance clauses who
>>  must keep what and when
>
>agree.
>
>>
>>11 - Section 3.5 general comment
>>This section is clearly very useful guidance!
>>It gives many clues for implementors. Please
>>make sure that these clues are also covered
>>in the DESCRIPTION clauses.
>
>Most already are in the DESCRIPTION clauses.  We will make
>sure DESCRIPTION clauses are useful.
>
>>
>>12 - p.14
>>all the "|t" are typos?
>>
>
>"t" indicates tables (as indicate in the top of the page.)
>
>>13 - p.16 key assumption 1
>>Looks like a limitation - is this necessary?
>>E.g., the entity mib may help you?
>>Also the wording is ambiguous. e.g., does
>>this mean 1 agent per 1 node?
>
>The way the index is defined, the MIB is designed for
>managing a single DLSw entity.  There are techniques
>available, e.g., the entity mib, community name, to
>allow an agent to appear as multiple MIB instances,
>thus multiple DLSw entities.
>
>suggest wording:
>"The MIB is designed to manage a single DLSw entity."

fine, if its clear what how an entity is defined in this context.
(agents always represent an entity).

>
>>
>>14a - p.16 Note 1
>>This structure somewhat fuzzy to me.
>>Judging from some objects where this is used:
>>- the timeticks flagging the valid event
>>  should always be used to make sure the sampling
>>  interval is correct
>>- if a value is unreliable before and reliable
>>  after a certain time, you could consider to create a TC
>>  with SYNTAX Gauge that restarts at 0 at each event
>>- i noticed some Counter32 cases that use this structure
>>  but where the counter instances do not even exist
>>  before the event (e.g., p.40)
>
>The sole purpose of "--## VALID" is to identify the
>TimeTicks object that valids the sampling interval
>is correct (e.g., the row entry of the same index
>maybe destroyed and created between two samplings).
>We can remove that structure if it is too confusing.

with th reorganization regarding timestamps i assume
you're now relying on sysUpTime. in that case
i wouldnt put the VALID statement in here since
counters are always dealt with using sysUpTime.
thus the statement may be confusing.
in any case, if there is something important stuff
regarding the behavior of an object the best place is in
the DESCR clause which can be picked up by MIB browsers.

>
>I don't see you last point (" ... where the counter instances
>not even exist before the event ...").

that referred to e.g., the dlswTconnOperTable - the connection
must first exist before the counters can be used.

>
>>
>>14b - p.16 Note 2
>>Would be better to flag in the DESCRIPTION
>>of the trap definition how the trap generation
>>is controlled.
>
>fine.
>
>>
>>15 - p.18 1st line:
>>Since this is just a syntax definition suggest to
>>replace "alength of zero.." with "the address is a
>>zero length string."
>
>agree.
>
>>
>>16 - DlswTimeStamp
>>This refers to dlswNodeUpTime?
>>More importantly, why is this clock necessary and
>>cant sysUpTime be used? Synchronization with multiple
>>clocks tends not to save you headaches.
>>This was raised in other MIBs as well. It seems to me that
>>using sysUpTime only is sufficient for this MIB.
>
>I believe the following was agreed by the working group and
>is consistent with SNANAU WG:
>
>DlswTimeStamp textual convention is removed.
>
>The following objects have modified definitions as follows:
>- dlswTConnConfigLastModifyTime
>    duration since last change to row
>- dlswTConnOperEntryTime
>    duration since the oper row was created
>- dlswTConnOperConnectTime
>    duration since the TC went "connected"
>- dlswTConnOperDiscTime
>    duration since the TC last went "disconnected"
>- dlswCircuitEntryTime
>    duration since the circuit table row was created
>- dlswCircuitStateTime
>    duration since the circuit last changed state
>
>Note that dlswNodeUpTime stays as it was, because it was already a
>duration.
>
>>
>>17 - p.21 DisplayString
>>The SIZE limitation is redundant.
>
>agree
>
>>
>>18 - p.22
>>dlswNodeUpTime - as per 16
>
>See 16.
>
>>
>>19 - p.22 bottom object
>>Redundant "can be found in"
>
>agree
>
>>
>>20 - p.25 ConfigIndex
>>"managed station" --> "agent"
>>This is a global comment. Avoid
>>things like "Management station",
>>"an implementation", "NMS" and talk
>>in terms of "agent" and "manager". It
>>tends to be more precise.
>
>will use the terms of "agent" and "manager:.
>
>>
>>21 - p.30 first DSECRIPTION
>>Here are some examples of the point in
>>item 20 above. Other examples in p.33
>>first object, etc.
>
>agree
>
>>
>>22 - p.56 1st DESCRIPTION
>>The last sentence is redundant and is
>>also SNMP-version-specific. Suggest to
>>remove it.
>
>The sentence is used to describe the behavior of the
>table.  Do you mean GET-NEXT is SNMP-version-specific?

no, but get-bulk is. the point is that this sentence is
- standard snmp and not specific to this table
- confusing by omitting get-bulk

>
>
>>
>>23 - p.56 2nd DESCRIPTION
>>As in 22 (and who are "we").
>
>it means the agent.  Will reword the sentence.
>
>>
>>24 - p.57
>>As in 22 and 23
>
>see 22 and 23
>
>>
>>25 - p.61 last object
>>To which row is this pointer pointing?
>
>All InstancePointers (obsoleted in RFC1903) are changed to RowPointer
>(the name of the instance of the first accessible columnar object
>in the conceptual row, as defined in RFC1903).  For the specific
>case, the conceptual row of the underlying DLS MIB of this
>circuit.

ok. my point was that you should specify a specific table rather than a MIB
(which may contain multiple tables).

>
>>
>>26 - p.88
>>Update references [2], [4-6].
>
>agree.
>
>>
>>
>>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>>_/                                                                      _/
>>_/  Kaj Tesink                                                          _/
>>_/  Bellcore                                                            _/
>>_/  - Broadband Data Services & Consulting  vmail (908) 758-5254        _/
>>_/    331 Newman Springs Rd.                email [email-masked]   _/
>>_/    Red Bank, NJ 07701                  faxmail (908) 758-4177        _/
>>_/                                                                      _/
>>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/                                                                      _/
_/  Kaj Tesink                                                          _/
_/  Bellcore                                                            _/
_/  - Broadband Data Services & Consulting  vmail (908) 758-5254        _/
_/    331 Newman Springs Rd.                email [email-masked]   _/
_/    Red Bank, NJ 07701                  faxmail (908) 758-4177        _/
_/                                                                      _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/